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Sudhakar Mamillapalli, assignors to Cisco Technology, Inc., a California 
Corporation. 

5 SPECIFICATION 

TITLE OF INVENTION 
FILE SYSTEM FOR NONVOLATILE MEMORY 

10 

» 

BACKGROUND OF THE INVENTION 
Field of the Invention 

15 The present invention relates in general to memory devices, and more 

particularly file systems suitable for use with nonvolatile memories. 

The Background Art 

20 As is known to those skilled in the art, numerous file system 

implementations have been developed. Most file systems known in the art have 
been developed with the assumption that the files would be stored on a magnetic 
disk or - in the case of data networking implementations - on a magnetic disk 
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attached to a network file server ("NFS"). Typically, files are divided into data 
blocks, and these blocks are laid out on the disk in which the files are to be stored. 
The layout of the blocks on the disk is typically optimized for minimizing the 
access time for file blocks stored on these disks. These file systems are normally 
5 very large, and hence very efficient file searching strategies have been developed. 

Most file systems known in the art assume that a complex directory 
structure will be imposed on the files, and hence complex data structures have 
typically been required to handle them. However, other file systems known to 

10 those skilled in the art store files in a contiguous fashion. For example, on some 
types of nonvolatile memory, such as flash memory media, files are typically 
stored in a contiguous fashion on the flash card containing the flash memory. In 
such a flash memory medium, there is typically no concept of "file blocks" 
involved. As known to those skilled in the art, however, flash media has its own 

15 peculiarities. For example, flash media typically must be reformatted to regain 
lost space. 

Nonvolatile (sometimes written as "non-volatile") random access memory 
("nvram," or "NVRAM") is typically a form of static RAM whose contents are 
20 . saved when a computer is turned off or loses its external power source. As is 
known to those skilled in the art, nvram may be implemented in various ways, 
including by providing static RAM with backup battery power, or by saving its 
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contents and restoring them from an Electrically Erasable Programmable Read 
Only Memory ("EEPROM"). 

The development of nvram enabled files to be stored in a system in a 
5 persistent way. However, existing file systems are inadequate for addressing the 
unique set of challenges presented by the nvram memory storage media. First and 
foremost, the nvram media is relatively small in terms of memory capacity 
(typically ranging from a few hundred kilobytes to a few megabytes). Thus, only 
a relatively small number of files can be stored on the media. Secondly, nvram 
10 can be accessed relatively quickly, in comparison to magnetic disks, and hence 
disk block layout is not a major factor that affects the seek time parameter. Also, 
no directory structure is typically imposed on the nvram medium. 

Moreover, because critical system data is often stored in nvram (e.g., 
15 cryptographic keys, system start-up configuration files, or other types of secure 
files), an nvram file system must be reliable. Specifically, a system "crash" should 
not corrupt the file system. In order to deal with these problems, a simple but 
elegant file system storage for the nvram medium is disclosed herein. It provides 
all the necessary functionality without being burdened by unnecessary details and 
20 restrictions imposed by a traditional file system. The main assumptions of the file 
system design according to embodiments of the present invention are that (1) the 
file system structure is flat (i.e., does not contain directories), and (2) a relatively 
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small amount of memory space is available. Also, an important design goal is not 
to have excessive file system information in the nvram memory medium at any 
given time. Most of the information is kept on the nvram, and based on this, other 
information may be obtained. Thus, a system crash will not result in loss of vital 
5 information which might have been buffered in memory. These and other features 
and advantages of the present invention will be presented in more detail in the 
following specification of the invention and in the associated figures. 
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SUMMARY OF THE INVENTION 

A file system for nonvolatile memory media is disclosed, based on the 
* (I 
assumptions that the file system structure is flat (i.e., does not contain directories), 

and that a relatively small amount of memory space is available. The nonvolatile 

5 memory medium is divided into logical blocks of predetermined size, depending 

on the typical file size expected for each particular implementation. Each of these 

logical blocks includes a header describing the contents of the block. For 

example, the block header may comprise a magic number indicating whether the 

block is a valid file system block or a free block, the name of the file to which the 

10 current block belongs, a flag indicating whether the current block is the first or last 

block of the file, the block number of the next block of the current file, if any, and 

the length of valid data in the present block. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating a nonvolatile memory medium 
5 logically partitioned into memory blocks according to aspects of the present 
invention. 

FIG. 2 is a block diagram illustrating the structure of a memory block 
according to aspects of the present invention. 

10 

FIG. 3 is a block diagram illustrating the software structure of an nvram file 
system manager according to embodiments of the present invention. 

FIG. 4 is a block diagram illustrating the interaction of the software 
15 components comprising an nvram file system according to one embodiment of the 
present invention. 
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DETAILED DESCRIPTION 

Those of ordinary skill in the art will realize that the following description 
of the present invention is illustrative only and not in any way limiting. Other 
5 embodiments of the invention will readily suggest themselves to such skilled 
persons, having the benefit of the present disclosure. 

FIG. 1 is a block diagram illustrating a nonvolatile memory medium 
logically partitioned into memory blocks. according to aspects of the present 
.10 invention. As shown in FIG. 1, in one embodiment, a 128 Kbyte nvram medium 
100 is logically divided into 128 1-Kbyte blocks 110-1 - 110-128. Each 1 Kbyte 
block 110-N comprises a block header portion 120-N and a data portion 130-N. 
Throughout this document, like elements will be referenced using the same label. 

15 FIG. 2 is a block diagram illustrating the structure of an exemplary memory 

block 110-N according to aspects of the present invention. As shown in FIG. 2, 
each memory block 110 comprises a header portion 120 and a data portion 130. In 
one embodiment, the header portion 120 comprises a magic number field 122, a 
next block pointer field 123, a flags field 124, a length of valid data field 126 5 a 

20 file name field 128, and a checksum field 129. 
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In the context of the present invention, a "magic number" means any 
identifying number that can indicate whether a given block is a valid file system 
block. A "valid block" is a block which belongs to a file, as described below. In 
its simplest embodiment, a magic number is a single bit indicating whether a block 

5 is a valid file system block. Preferably, however, the magic number contains 
multiple bits so as to provide protection against data corruption in the memory 
medium. In one embodiment, the magic number is a 2-byte unique identifier that 
is the same for all valid blocks. In this embodiment, a block with the magic 
number field 122 equal to the magic number is considered to be a valid block. 

10 The specific choice of magic number is not critical, and those skilled in the art will 
recognize that different magic numbers of varying data width may be used 
depending on each particular implementation. It should be noted that the magic 
number should be chosen so that it is not likely to be present randomly (e.g., upon 
system power-up). 

15 

In one embodiment, next block pointer field 123 contains a pointer to the 
next block in the current file, if such a next block exists. . Depending on each 
particular implementation, next block pointer field 123 may contain the absolute 
nvram medium address of the next block in the current file, the block number of 
20 the next block in the current file, or any other identifier known to those skilled in 
the art for pointing to the next block. As described below, in one embodiment, 
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when a bit in the flags field 124 indicating that the current block is the last block 
of the current file is set, the value of next block pointer field 123 is ignored. 

In one embodiment, flags field 124 contains a first bit that is set if the 
5 current block is the first block of a file, a second bit that is set if the current block 
is the last block of a file, and a third bit that is set if the current block belongs to a 
secure file. Other variations on the number or types of flag bits or encodings for 
various implementations will be readily apparent to those skilled in the art. 

10 As described below, in one embodiment, the Length of Valid Data field 126 

contains a value indicating the number of valid data bytes in the current block. 

File name field 128 contains an alphanumeric or numerical code 
representing a file (if any) to which the current block belongs. According to 
15 aspects of the present invention, each "file" comprises one or more blocks, 
depending on the size of the blocks and the size of the file. 

Checksum field 129 contains a value that may be used to test the integrity 
of the data in each block. Any of a number of data integrity verification 
20 techniques known to those skilled in the art may be used to determine and test the 
value of checksum field 129. For example, without limitation, the value of 
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checksum field 129 may be equal to the sum of the values of all the data bytes in 
the block. 

' Data portion 130 contains a variable amount of data, ranging from zero 
5 bytes (for an empty valid block) to a number of bytes equal to the memory block 
size minus the memory block header size (for a valid block that is completely 
filled with data). For example, in one embodiment, the block size is 1 Kbyte (i.e., 
1024 bytes) and the block header size is 32 bytes, which means that the data 
portion of each memory block can hold a maximum of 992 data bytes. The 
10 Length of Valid Data field 126 in the header portion 120 of each valid memory 
block 110 (i.e., each block with a magic number field 122 having a value equal to 
the magic number) indicates the number of valid data bytes in the current block. 

As mentioned earlier, according to aspects of the present invention, a data 
15 file comprises one or more memory blocks 110 as shown in FIGs. 1 and 2. The 
blocks comprising a given file may be arranged in any order within the nvram 
medium. As discussed in more detail below, in one embodiment, the blocks 
comprising a given file may be read in order from the nvram medium by first 
scanning the nvram medium on a block-by-block basis, examining the block 
20 headers to find the first block of the file, and then following the next block 
pointers to find the next block in the file until the last block in the file has been 
found. 
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In one embodiment, a scan of the nvram medium is performed for a 
particular file name only when that particular file name is requested. When this 
occurs, the blocks are scanned to find all the blocks associated with the requested 
5 file. Similarly, when a free block is needed, the entire nvram medium is scanned 
on a block-by-block basis to determine whether each block has a valid magic 
number. If a block is found without a magic number, it is assumed to be a free 
block (i.e., a block that does not belong to any file), and is then used as the next 
block for a file if needed. In one embodiment, deletion of a file consists of 

10 "trashing" the magic numbers of the blocks composing the file (i.e., changing the 
magic number field so that it no longer contains the magic number). In this 
embodiment, a list of free blocks in the nvram medium is not kept, since there are 
a relatively small number of blocks (e.g., 128 1 Kbyte blocks in a 128 Kbyte 
nvram medium), and write operations to the nvram medium are not performed 

15 very frequently. Hence, a significant performance penalty is not incurred by the 
above approach. If so desired for a particular implementation, a list of free blocks 
can be maintained. 

Data Structures 

20 

In one embodiment, a number of data structures are used to implement 
aspects of the present invention. First, a block header structure stores the same 
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information that comprises each nvram block header 120 as shown in FIGs. 1 and 
2. This structure, called the nvram _blockJidr structure, starts off with a magic 
number, which is used to determine if the block is a valid block or not. The magic 
number is followed by the number of the next block for the current file, if any. 

5 Next, the flags structure member keeps track of whether the current block is the 
first block or the last block associated with the current file. It also indicates 
whether the current block belongs to a secure file or not. Secure files can be used 
to store sensitive information, such as cryptographic keys. If the secure bit is set, 
only processes which have validated themselves with a policy manager (not 

10 described herein so as not to overcomplicate the present disclosure) can read the 
blocks comprising the secure file. The next structure member, "length," indicates 
the length of valid data in the current block. Next, the "file name 55 structure 
member is a field with a maximum data size defined by the max_nvram_filelen 
variable, and stores the file name of the current file in the ASCII format known to 

15 those skilled in the art. Finally, the block header structure ends with a checksum 
equal to the value of the checksum field 129 shown in FIG. 2 and described above. 

The format of the block header structure is illustrated below. In one 
embodiment, the block header structure is arranged in the same way that as the 
20 memory block headers in the nvram medium. The memory block headers are 
stored on the actual nvram medium, whereas the block header structures are stored 
elsewhere on a system utilizing the nvram file system according to the present 
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invention. For example, the block header structures may be stored in main 
memory. 

#define NVRAM_FILE_FIRST_J3L0CK 0x01 

5 #def ine NVRAM_FILE_IAST_BLOCK 0x02 

#define NVRAM_FILE_SECURE_BLOCK 0x04 

. typedef struct nvram_jDlock_hdr_type { 

ushort mag ic_ number ; 

ushort next_block; 

10 ushort flags; /* a bit-wise OR of the flags 

defined above * / 

ushort length; 

char f ile_name[ MAX_NVRAM_FILELEN] ; 
15 ushort checksum; 

} nvram_block_hdr; 

For each open file, there is an associated file information structure, as 
defined below. The first member of this structure indicates the first block for the 

20 specified file, the second member indicates the current block being accessed, and 
the third member provides an offset within this current block. In one embodiment, 
the "flags" structure member is used to keep track of whether the file is a secure 
file or not, and whether a client is authorized to access this file. If the file is a 
secure file, the process must be validated before the file can be accessed, and when 

25 the process is validated, the flag indicating that the client can access the file is set. 
Finally, the "delete on close" flag indicates whether to delete the file when it is 
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closed. As is known to those skilled in the art, this feature is useful for secure 
files. 

#define NVRAM_FILE_SECURE 0x01 

5 #define NVRAM_FILE_ACCESS 0x02 

#define NVRAM_FILE_DELETE_ON_CLOSE 0x04 

typedef struct nvram_f ile_info_type { 

int first_block; /* # of 1st block for this file-*/ 

int currjDlock; /* # of current block */ 

10 int offset in curr block; /* offset relative to curr block */ 

char flags; /* bitwise OR of flags defined 

above * / 

15 } nvram_f ile_inf o; 

The geometry of the current nvram medium is stored in a structure defined 
below. In one embodiment, the first member of this "geometry" structure is the 
memory size of the nvram. The second structure member is the offset to the start 
20 of "useful" nvram. In some applications, an initial portion of the nvram medium 
may be allocated to a different file system, and therefore not usable for the 
purposes of the present invention. In such situations the offset structure member 
may be used to indicate the size of the nvram medium memory space allocated for 
other purposes. 

25 
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Next, the third structure member is the block size for each nvram block, 
while the fourth member is the number of such blocks present in the current nvram 
medium. 

5 The geometry structure is passed on to all format functions (described 

below) to enable them to handle each high-level nvram file function appropriately. 
The format of the geometry structure is shown below. 

typedef struct nvram_geometry_type { 
10 int nv_size; /* size of the nvram, in Kbytes */ 

int nv_ start; /* the offset for "useful^ nvram */ 

int blocksize; . /* size of each block, in bytes */ 

int no_blocks /* number of blocks */ 

} nvram_geometry; 

15 

NVRAM File System Manager 

To provide for seamless implementation of nvram file systems according to 
aspects of the present invention in a variety of hardware platforms, a common set 
20 of software functions (known as the "nvram file system manager") may be 
provided. FIG. 3 is a block diagram illustrating the software structure of an nvram 
file system manager 300 according to one embodiment of the present invention. 
As shown in FIG. 3, file system routines 310 are at the highest level of abstraction, 

15 
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and may be implemented as a function library. In one embodiment, file system 
routines 310 comprise the following functions: iojopenO (for opening a file), 
iojeadQ (for reading data from a file), iojwriteQ (for writing data to a file), 
iojoloseO (for closing a file), iojunlinkQ (for removing files), ioJseekQ (for 
5 moving the read/write file pointer), iojstatQ (for providing information on files), 
and initO (for initializing the file system). As is known to those skilled in the art, 
file system routines 310 may be grouped into or implemented as an Application 
Program Interface ("API"), static library, dynamic link library ("DLL"), or any of 
a number of other devices known in the literature. 

10 

Still referring to FIG. 3, file system routines 310 call the format routines 
320 to implement the sub-tasks necessary to execute each file system routine 310. 
In one embodiment, format routines 320 comprise the following functions: 
findJileJiyjiameQ (to find a specified file in the nvram medium, if it exists), 

15 read_nvramQ (to read data from the nvram medium), write_nvramQ (to write data 
to the nvram medium), set j)jfsetQ (to set the current block and offset members of 
the nvram_file_info structure), create JileO (to create a new file), geometry _init() 
(to initialize the nvram file system), erase JileO (to erase all the blocks comprising 
a specified file), get_listj)fJilesQ (for providing a directory of files in the nvram 

20 medium), close JileO (f° r closing a file), and get JilenameQ (for returning the 
filename to which a specified block belongs. In one embodiment, the format 
routines 320 are aware of the layout (or "geometry") of the nvram (e.g., the start 
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address of the nvram, the block size, number of blocks, etc.). This information is 
used to determine the amount of data to transfer, and from which block or blocks. 

In turn, format routines 320 invoke driver routines 330 to implement the 
5 most elemental subtasks necessary to execute the file system routines 310 and to 
actually interface with the nvram medium. In one embodiment, driver routines 
330 are further subdivided into platform independent routines 335 and platform 
specific routines 338. Platform independent routines 335 are elementary functions 
that are common to a wide variety of hardware platforms. In one embodiment, 
10 these functions comprise readjstuffQ (for reading data from the nvram medium), 
write jstuffO (for writing data to the nvram medium), and getjtvsizeQ (to 
determine the memory size of the nvram medium). 

Platform specific routines 338 are those elementary functions whose details 
15 differ depending on the specific hardware characteristics of each implementation. 
Typically, a new set of platform specific routines 338 must be developed 
depending on the hardware configuration of each implementation. In one 
embodiment, the platform specific routines include nv^getptrQ (for returning a 
pointer to the base address of nonvolatile memory), nvjdoneQ (for handling the 
20 writing of data to the nvram medium), nv_writeenable() (to enable further writes 
to the nvram medium), nv_writedisable() (to disable further writes to the nvram 
medium), nvJnitQ (to initialize the nvram medium), and nvJ>adptrQ (to handle a 
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bad block pointer). As is known to those skilled in the art, the platform specific 
routines 338 may be implemented as Dynamic Link Libraries ("DLLs") which are 
loaded onto a particular system depending on the hardware platform used in each 
implementation. 

5 

Using the above or an equivalent set of functions, embodiments of the 
present invention provide the required functionality to implement a functional 
nvram file system manager. Each of the functions in the three function groups 
listed above is described in detail in the sections that follow. Additional 
10 implementation details which are well within the routine programming skill of 
those skilled the art have are not discussed herein, so as not to overcomplicate the 
present disclosure. 

File System Functions: 

15 

The file system functions are the high-level functions invoked to perform 
normal file-oriented tasks such as open, read, write, erase, etc. Each of these file 
system function is described more fully below. 

20 
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io_openQ 

Open on an existing file involves searching for the block defining the first 
block of the file. Once the first block is known, the entire file can be accessed by 

5 following the "next block pointers" stored in the header. Hence, in one 
embodiment, when an open call is given, the nvram is scanned in sizes of one 
block. The block header is read in, and the magic number is tested. A valid magic 
number indicates a valid block, while an invalid magic number indicates a free 
block. If the block is a valid block, the file name is compared to the file being 

10 opened, and if it matches, the flag indicating if the current block is the first file 
block associated with this file is tested. If it is not the first block, the scan is 
continued until either the first block of the specified file is encountered or an error 
condition occurs. 

15 Open on a nonexistent file involves finding a free block (which in one 

embodiment involves finding the first block with an invalid magic number). This 
free block header is then modified to write the magic number into the magic 
number field* of the block header, the name of the file to be opened, the flags 
described above, and other relevant information as required by a particular 

20 implementation. 
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From a software standpoint, after verifying the file permissions, the high 
level iojopenQ function calls the find Jile_by_nameQ function with the file name 
to be opened. If the specified file exists, an nvram _JileJnfo structure is filled in 
by this function. If the open is for read, and the file does not exist, then the open 
5 fails. If the file exists and the open is for write then, the file is truncated to zero 
length. If the file is opened for write and the file does not exist, a new file is 
created if at least one free block is available. 

iojreadO 

10 

Read involves reading the data in the blocks associated with the file. When 
a read command requests an amount of data greater than the data in the present 
block, the read is continued to the next block associated with this file. The lower- 
level read_nvramQ function (described below) is called with a buffer, which fills 
1 5 in the buffer with the required data. 

iojwriteO 

The io_writeQ function is substantially similar to ioj-eadQ^ with data being 
20 written to the current block. If the amount of data to be written is greater than the 
amount of data that would fit into a block, and if the current block is the last block 
of the file, a new free block is found and attached to the end of the file, at which 
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point the write operation continues in the newly found block. Similarly to 
iojreadO* the write jnvramQ function is called, except that this time the buffer 
passed to the function is written into nvram as file data. 

io_close() 

If the flags associated with the nvram Jilejnfo structure (described earlier) 
indicate that the "delete on close" flag has been set, then the file is erased by 
calling the lower level erase JileQ function. Otherwise, the nvram _JHeJinfo 
structures are freed and the current block is marked as the last block for this file, if 
this file has been opened for write. 

ioj>eek() , 

An io_seekQ function involves traversing the list of blocks until the desired 
offset is reached. In one embodiment, this function is typically not used, since file 
operations are performed on a block by block basis. However, the iojseekQ 
function may be useful in situations where block synchronization has been lost for 
some reason. As in previous cases, if the offset is greater than the data in the 
current block, a jump is made to the next block based on the next pointer stored in 
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the header of the block. The iojseekO function calls the lower level set_pffset() 
function. 

initO 

5 

The initQ function calls the lower level geometry JnitO function, which is 
responsible for filling in the geometry information for the current nvram medium. 

iojmlinkQ 

10 

The iojmlinkQ function is used to delete files. A delete involves the 
simple operation of traversing all the blocks comprising the specified file starting 
from the first block, and overwriting the magic number field in each such block 
with a value not equal to the magic number. The lower level erase JileO function 
15 is called. 

io_stat() 

20 The iojstatO function is normally used to provide information concerning 

specified files. In one embodiment of the present invention, all the io_stat() 
parameters are set to zero except for the mode and size, which are copied from an 
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attribute structure. In this embodiment, for the directory parameter, the size is set 

« » 

to 1. 

Nvram Format Functions 

5 

The nvram format functions are lower-level building blocks called by the 
high-level file-oriented functions to implement the details of each file-oriented 
function. These functions are aware of the nvram format from the nvram 
geometry structure, and are called by the file system functions to manipulate the 
10 nvram file system. Each nvram format function according to one embodiment of 
the present invention is described in more detail in the following sections. 

int readjivram (nvram Jilejnfo *file, nvram_geometry * geometry, char * buffer, 
intbuflen) 

15 

Given the nvram _geometry and nvram _Jile_info structures, the 
readjivramQ function reads an amount of data equal to buflen from the specified 
file into a buffer, and returns the amount of data that was read. Since the nvram 
geometry is known, a readjivramQ call is converted into a series of calls for each 
20 block comprising the specified file, and the lower level readjstuffO function is 
called (described below), which is a driver function responsible for actual reading 
of data from the nvram. 
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int write jivram(nvr am Jilejnfo *file, nvr -am ^geometry ^geometry, char *buffer, 
int buflen) 

The write jivramQ function is substantially similar to the read_nvram() . 
5 function, except that the write jstuffQ driver function is the driver-level function 
which is called to ultimately write data to the nvram from the buffer. Also, if at 
end of the specified file, further writes result in a search for a free block which, if 
available, is added to the list of blocks associated with this file. The 
nvram Jilejnfo structure is also updated accordingly. 

10 

int find Jilejyjiame (char *name, nvramjgeometry ^geometry, nvram Jilejnfo 
*file) 

Given the nvram geometry, this function scans all the blocks in the nvram 
15 medium for a specified file having a particular name, and fills in the 
nvram Jilejnfo structure passed on to it when the specified file is found. It 
returns the file size, if the specified file is found. If the file does not exist, the 
function returns (-1). 

20 int setjoffset (nvram Jilejnfo file, int offset) 

The setjoffsetQ function, when passed the nvram Jilejnfo structure and an 
offset into the specified file, sets the current_block and offset_in_curr_block 
members of the nvram Jilejnfo structure appropriately. 
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int create Jile (nvram ^geometry * geometry, nvram Jilejnfo *file, char ^filename, 
bool secure) 

5 The create JileQ function is called if a new file with name "filename" 

needs to be created. The create JileO function finds a free block, if any are 
available, fills in the appropriate header information, and returns. If the secure file 
parameter is true, then the file block created is set to be a secure block, and if the 
secure file parameter is not true, the file block created is set to be a non-secure 
10 block. 

int geometry Jnit (nvram geometry * geometry) 

The geometry JnitQ function is called before the nvram driver is started. It 
15 is responsible for filling the geometry structure. It calls nv JnitQ, and also uses the 
get_nv_sizeQ function to fill in the geometry structure. All of these functions are 
driver-specific functions. Once the geometry is known, the geometry JnitQ 
function "sanitizes" the nvram. This step is needed to ensure the consistency and 
reliability of the nvram file system. For example, if an application accessing the 
20 nvram crashes in the middle of writing a file, the geometry JnitQ function is 
responsible for scanning through the nvram and removing any partial files 
remaining upon the next system startup. Also, it is possible that some of the file 
blocks may have been overwritten during a previous bootup. Therefore, once the 
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nvram geometry is known, the geometry JnitQ function scans through all the file 
blocks in the nvram, deleting any partial files and ensuring that all the blocks of 
every file are available and that there are no dangling blocks (i.e., blocks not part 
of any file). 

5 

int erase Jile(nvr am geometry * geometry, nvram JileJnfo*file) 

In one embodiment, when the erase JileQ function is called, all blocks 
comprising the specified file described by the nvram Jilejnfo parameter are 
10 zeroed out 

int get JistjDfJlles (char ^buffer, nvramjgeometry * geometry, int remjsize, int 
offset, int *size) 1 

15 The getjistj>fjiles() function returns a list of all the* files present in the 

nvram. In one embodiment, the entire nvram medium is scanned on a block-by- 
block basis, and the file name field (encoded in ASCII) from each block header is 
read in for all valid blocks. In this embodiment, when duplicate file names are 
read in, they are assumed to be additional blocks of the same file. The complete 

20 list of file names (with duplicates deleted) is written into a buffer upon return from 
the get JistjDfJlles 0 function. 
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int close Jile(nvram Jilejnfo *file, nvramjgeometry ^geometry) 

The close JileQ function is called when a file opened for write is called. 
The last block flag is set, and the header for the last block is written. 

5 

int get Jilename(int block jio> nvramjgeometry* geometry, char ^filename) 

Given a specified block number ("blockjio"), the get JilenameQ function 
returns the file name to which the specified block belongs, if any. 

Driver Functions 

The file system and nvram format functions discussed above access the 
nvram medium through the nvram driver interface routines defined below. As 

15 discussed in the Interface Design section, below, a platform specific DLL, linked 
in when an nvram file system manager process starts, is responsible for providing 
a pointer to the functions below. Each driver function according to one 
embodiment of the present invention is described in more detail in the following 
sections. In many cases, implementation details are not provided herein so as not 

20 to overcomplicate the present disclosure. Such implementation details are well 
within the capabilities of those skilled in the art. 
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int readjstufffint offset, char * buffer, int len) 

Given a offset and a buffer, the readjstuffO function reads "len" data bytes 
from the nvram medium at "offset" from the beginning of the nvram medium, and 
5 writes the results to the specified buffer. The function returns the length of data 
read. 

int writejstufffint offset, char *buffer, int len) 

10 The write jstuffQ function is substantially similar to readjstuffO, except that 

"len" data bytes from the specified buffer are written into the nvram medium 
starting at "offset," and the length of data written is returned. 

int start _ofjisable_memoryQ 

This function returns an offset from the beginning of nvram, indicating the 
point at which nvram media allocated for other purposes or file systems ends. 

intgetj^vjsizeQ 

20 

The getjiv_size() function returns the size of the current nvram medium. 
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In one embodiment, the nvramQ function simply calls geometry JnitQ. 

5 bool other _JilesystemjexistQ 

This function either returns true or false, depending on whether other file 
systems exist on the current nvram medium. 

10 void collect j?latformjdependent_yalues (platform _values *platform_yals, 
nvram jplatformjill Junes *nvramJriverJnterfacejroutines) 

This function collects all the platform dependent routines needed through 
this call. This is defined by the structure platform _yals. The function also fills in 
15 the addresses of platform independent routines in the 
nvram jdriverJnterface_routines structure, which is the interface through which 
nvram driver is accessed to the caller. This is then passed to the nvram file system 
manager process. This function is described in more detail in the Interface Design 
section, below. 

20 

nvtype *nv_getptr(void) 

This function returns a pointer to the base address of the non-volatile 
memory. 
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void nvjdonefnvtype *ptr) 

This function handles the writing of data to the nvram memory. 

5 

void nv_writeenable(nvtype *ptr) 

This function simply turns the nv_write enable flag on. 

10 void nv_writedisable(nvtype *ptr) 

This function simply turns the nv_write enable flag off. 

unsigned long nv Jnit(unsigned long *phyjxddress) 

This function discovers the size of the nvram and performs some 
initialization. The function returns the system address at which the nvram has 
been mapped. Also, the argument passed is filled in with the actual physical 
address at which the nvram has been located. This informatioa can be used to 
convert physical to virtual addresses and vice versa, since in some nvram file 
system implementations cases the actual physical address may be important. 
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bool nvjbadptr(nvtype *ptr) 

Given a correctly checksummed portion of non-volatile memory, the 
nvJbadptrQ function examines the data structure components for sanity. If the 
5 configuration magic number is set, the function returns zero. 

Interface Design 

In one embodiment, the nvram file system provides a posix interface for 
10 using the nvram medium. However, the interface for opening and accessing 
secure files is typically separate, and has been discussed in the API functional 
description above. 

FIG. 4 is a block diagram illustrating the interaction of the software 
15 components comprising an nvram file system according to one embodiment of the 
present invention. As shown in FIG. 4, the nvram file system 400 comprises the 
nvram file system manager process 410, a platform-common DLL 420, and a 
platform-specific DLL 430. The nvram file system manager process 410 accesses 
the platform specific functions, through indirect function calls defined in the 
20 structure of type nvram jylatformjill Junes, This structure has a number of 
function calls, which the process calls through this structure to gain access to the 
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physical nvram medium. The structure with these functions must be provided by 
the platform-specific DLL 430. 

When the nvram process 410 starts up, it opens the platform-specific DLL 
5 430 and performs the common dlsymQ DLL access function known to those 
skilled in the art on NVRAM JDLL_PLATFORM^ . 
This should return a pointer to a function which returns a structure of type 
nvram jilatformjill Junes with function addresses filled in by the platform 
specific DLL 430. As long the platform specific DLL provides a way for 
10 returning this function, that is all that is needed to provide a fully functional nvram 
file system. 

In order to simplify the nvram file system creation process, the platform- 
common DLL 420 is also provided. In some applications, it is not necessary to 
15 use this DLL at all. However, platform-common DLL 420 defines the functions in 
nvram _platform_dll Junes that were defined in the previous paragraph. In one 
embodiment, the platform-common DLL 420 must also deal with platform 
specific issues. 

20 As shown in FIG. 4, it should be noted that the nvram file system manager 

process 410 accesses the nvram medium through functions defined in 
nvram j)latform_dll Junes, which are subsequently defined in the platform- 
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common DLL 420. It is however, the duty of the platform-specific DLL 430 to 
pass the addresses of these routines to the nvram file system manager process 410. 
In order to accomplish this, the platform-specific DLL 430 must obtain the 
addresses of these routines from the platform-common DLL 420 and pass them on 
5 to the nvram file system manager process 410. Also, the platform-common DLL 
420 uses platform specific routines defined in the platform-specific DLL 430. 
Therefore, the addresses of routines in the platform-specific DLL 430 are also 
needed. 

10 Still referring to FIG. 4, to accomplish the above tasks, as soon as the 

nvram file system manager process 410 starts, it makes a function call to the 
function that had been obtained by performing dlsymQ on 
NVRAM_DLL^PL ATFOm^INTERF ACE_ROUTINES . This function call then 
makes another call to a function called collect jplatformjiependentjyalues() in the 

15 platform-common DLL 420 with two parameters. The first parameter is a 
structure of type platform values, with all the platform-specific function pointers 
filled in for the receiver's (i.e., the platform-common DLL 420) use. The second 
parameter is a pointer to a structure of type nvram jplatformjill Junes. When the 
platform-common DLL 420 receives the function call, it saves the first parameter 

20 and fills in the second parameter with the nvram interface routine function 

addresses/ Upon return, the platform-specific DLL 430 passes the information on 

to the nvram file system manager process 410. 
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To achieve this, the platform driver must provide such a function. The 
details of this process are not disclosed herein, so as not to overcomplicate the 
present disclosure. However, providing such a function should be well within the 
5 capabilities of those skilled in the art, and requires only application of routine 
programming skills. The definition of the nvram jplatformjill Junes structure and 
of the platform values structure are provided below. 

typedef struct nvram_platform_dll_funcs_ { 
10 int (*read_stuff ) (int offset, char *buffer, int len) ; 
int (* write_stuf f ) (int offset, char *buffer, int len) ; 
int (*get_nv_size) () ; 

int (* classic_nv_open) (long *size, unsigned char **-data) ; 
void (*nvram_init) (); 
15 } nvram_j>latf orm_dll_funcs ; 

The above structure contains a pointer to the nvram interface routines discussed in 
previous sections. 

20 typedef struct platform_values_ t { 

nvtype * (*nv_getptr) (); 

bool (*nv_badptrj (nvtype *ptr) ;. 

void (*nv_done) (nvtype *ptr) ; 

void (*nv_writeenable) (nvtype *ptr) ; 
25 void (*nv_writedisable) (nvtype *ptr) ; 
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void (*nv_init) (void); 
int (*getmonvar) (unsigned char **buf); 
int (*nv_size) () ; 
int (*nvwriteflag) () / 
5 ) platf orm_values; 

The pointer to functions in the above structure are same as pointers to platform 
specific functions needed by the platform-common DLL 420 to get the work done, 
along with a few variables shared with it. 

10 

Crash Recovery 

If the nvram subsystem crashes, when a system utilizing an embodiment of 
the nvram file system according to the present invention boots up again, a "sanity 

15 check" is made to make sure that the files in the nvram are in a consistent state. 
The following actions are taken if an inconsistent file is found: If a loose block is 
found, the block is deleted. If a file is found with any missing blocks, the entire 
file is deleted (i.e., all the blocks containing the file name in the block header are 
converted to free blocks by overwriting the magic number field with a value not 

20 equal to the magic number). If multiple files exist with the same file name, the 
first such file is kept and the rest are deleted. If the last block of a file does not 
have the "last block of file" flag set but has the "next block" set to zero, then the 
"last block of file" flag is set. 
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Advantages 

As those skilled in the art will recognize based on the above discussion, file 
5 operations according to embodiments of the present invention are simple and 
provide all the functionality required for typical nvram file system applications. 

There are several advantages of embodiments of the present invention as 
compared to traditional file systems. First, unnecessary details associated with 

10 disk-based file systems have been eliminated, thus keeping the code simple and 
easy to maintain. Moreover, at any given time, the file system on the nvram is 
self-sufficient, such that no vital information is kept in the memory for a long 
enough time that a system crash would corrupt the file system due to unwritten 
information. Furthermore, compared to file systems where data is written 

15 contiguously, such as flash file systems, the file system design according to 
aspects of the present invention achieves less fragmentation and allows multiple 
writes simultaneously. In general, it is difficult to achieve multiple writes on a file 
system where data is written contiguously, since it is difficult to determine how 
long the files would be. Also, such a file system storage suffers from more 

20 fragmentation. 
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For example, if a contiguous file system had four files stored on it (e.g., 
files A, B, C, and D, each of size 1 Kbytes), and if files B and D have been 
deleted, it is not possible to coalesce the remaining free memory together to obtain 
a contiguous memory area of 2 Kbytes. Therefore, files greater than 1 Kbytes 
5 cannot be saved. In contrast, in the file system design proposed according to the 
present invention, fragmentation is limited at most by the selected block size. For 
a typical block size of 1 Kbytes with a 32-byte header, the amount of lost space 
due to the header is less than 4%. Since nvram media are typically used to store 
small files, this proportion of lost memory space due to headers is generally 
10 acceptable. 

As is known to those skilled in the art, the program code necessary to 
implement the software components described herein according to aspects of the 
present invention may all be stored on a computer-readable medium. Depending 

15 on each particular application, computer-readable media suitable for this purpose 
may include, without limitation, floppy diskettes, hard drives, RAM, ROM, 
EEPROM, nonvolatile RAM, or flash memory. Moreover, the program code 
necessary to implement the software components described herein according to 
aspects of the present invention may be executed by any processor or combination 

20 of processors known in the art, including, without limitation, microprocessors, 
microcontrollers, Application Specific Integrated Circuits ("ASICs"), or other 
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types of commercially available hardware or firmware devices suitable for that 
purpose. 

While embodiments and applications of this invention have been shown 
5 and described, it would be apparent to those skilled in the art having the benefit of 
the present disclosure that many more modifications than mentioned above are 
possible without departing from the inventive concepts herein. For example, 
without limitation, additional data such as . a previous block pointer may be 
included in the header portion of each memory block if so desired. As another 
10 example, embodiments of the present invention may be implemented wherein only 
a portion of an nvram medium uses a file system according to the present 
invention, and another portions of the nvram medium are organized in some other 
fashion. The present invention, therefore, is not to be restricted except in the spirit 
of the appended claims. 
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